跳到主要内容

以 SLO 为导向的故障处理流程

最后 更新

SLO(Service Level Objective) 即服务级别目标,是定义服务质量和可用性的一种指标。 更多关于 SLO 介绍可参考:SLO简介

为什么要可观测性要围绕着 SLO 展开?

通过数据驱动和SLO定义,量化服务质量,根本上提升服务可靠性,使团队具备专家视角处理风险。

围绕 SLO 来展开可观测性工作,可以帮助用户将注意力从庞杂的指标数据中解放出来,通过量化服务质量,基于数据驱动和 SLO 定义,从根本上提高服务可靠性,让每个团队都能具备专家视角来处置和管理风险 SLO(Service Level Objective,服务级别目标)是一种用于衡量企业或组织内部服务质量的指标。相较于传统观测指标,SLO具有以下优势:

  1. 针对性:SLO 是根据业务需求和用户期望制定的,更具针对性。传统观测指标可能过于宽泛或繁琐,不能直接反映用户关注的重点。SLO 可以帮助企业更好地满足用户需求,提高客户满意度。
  2. 简洁性:SLO 旨在衡量关键服务特性,通常不超过5个,使得指标体系更简洁。相较于传统观测指标,SLO 更易于理解、监控和沟通。
  3. 可量化:SLO 要求具备可量化的数据支持,有利于对企业内部服务质量进行客观、精确的评估。这有助于发现潜在问题,为改进服务提供依据。
  4. 动态调整:SLO 可以根据业务发展和用户需求的变化进行动态调整,更具灵活性。企业可以根据实际情况,设置合理的 SLO,确保服务质量始终符合要求。
  5. 结果导向:SLO 关注的是服务结果,而非过程。这有助于企业关注核心业务,提高工作效率。
  6. 持续改进:通过监控和分析 SLO 数据,企业可以不断优化服务流程,实现持续改进。这有助于提升企业竞争力,适应不断变化的市场环境。 总之,SLO 作为一种更具针对性、简洁性、可量化、动态调整、结果导向和持续改进的优势指标,可以帮助企业更好地监控和提升服务质量,从而满足用户需求,提高客户满意度。
  7. 围绕着 SLO 可以标准化落地 1-5-10,告警可以收敛到业务层,聚焦到处理业务层 SLO 违反的原因。只要识别 SLO 违约的原因,并在10分钟解决 SLO 违约的原因,即可落地1-5-10。

为什么要以SLO来组织告警?

主要有以下几个原因:

  1. SLO 能够量化服务质量,定义明确的目标期望。这为告警设置提供清晰的指标和阈值。
  2. SLO 遵守情况直接关乎到用户的满意度。SLO 告警可以让服务提供方时刻关注真正重要的服务质量信号。
  3. 基于 SLO 组织告警,可以减少不必要的、与服务质量无关的告警。避免告警疲劳。
  4. 当 SLO 被违反时,说明服务已不能满足用户需求。这是服务提供方必须响应的关键信号。
  5. SLO 违反后需要快速定位根因、修复问题恢复服务。围绕 SLO 展开故障响应机制可以有效降低服务中断影响。

综上,以 SLO 为核心展开监控和告警策略,可以让服务提供方更加聚焦关键的服务质量,并在质量下降时快速响应。这提高了用户满意度,也促进服务提供方主动优化系统,从而有助于双方获益。

Kindling-OriginX 提供以SLO为导向的故障处理流程

该处理可以简单的概括为三个步骤:

  1. SLO 异常检测,检测 SLO 是否违反。
  2. 如果 SLO 违反,生成典型的故障报告,以算法及专家经验自动组织和关联分散的监控指标、日志,自动数据降噪,最终直接生成故障根因报告。
  3. 用户参照故障根因报告,根据报告与建议指导快速完成应急处置,落地 1-5-10(1分钟发现故障,5分钟识别故障初因,10分钟完成故障恢复)

将 Kindling-OriginX 基于 SLO 导向的故障处理流程与传统故障处理流程做一对比可以发现,其能够在故障处置流程中极大的缩短 MTTR,同时能够让参与处置的人员更关注在核心问题上。 图1:Kindling-OriginX 基于SLO导向的故障处理流程

为什么使用 Kindling-OriginX 只需要关心 SLO 的告警?

在传统的可观测性系统中,SLO 仅反映了服务层面的指标,当SLO被违反时,并不直观知道具体的根因。是后续接口错误率升高了导致,亦或是流量异常所导致,还是依赖的服务出现问题,这些都可能是导致 SLO 被违反的罪魁祸首。 在传统的可观测性系统中,需要通过额外监控每个接口错误率、流量、依赖服务健康状况、CPU 利用率,流量等其他指标,并设置告警,从而帮助快速定位根因。 Kindling-OriginX 创新的以专家智慧经验与算法自动组织可观测性数据,直接给出故障根因,帮助技术人员更好更精准的理解为什么 SLO 会被违反,不再需要通过其他指标的告警来进行额外的人工分析和决策判断。

可以只使用 Kindling-OriginX 的 SLO 告警吗?

既然 Kindling-OriginX 这么神,是否应该直接放弃已经建立的告警体系,只使用 Kindling-OriginX 的 SLO 告警?理论上 Kindling-OriginX 成熟之时,确实可以放弃其他指标的告警,现在 Kindling-OriginX 刚刚诞生,在全球也是首创的故障根因推导技术,建议仍然保留原有的告警体系,两者共存一段时间。如果发现Kindling-OriginX 的故障报告有不准的地方,欢迎提交反馈,我们一起让 Kindling-OriginX 成熟起来,让每家公司都可以实现以 SLO 为导向的故障处理流程。